home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 12 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.5 KB
  1. Path: chronicle.mti.sgi.com!news
  2. From: ark@research.att.com (Andrew Koenig)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: RTTI implementation...
  5. Date: 08 Jan 1996 23:02:07 GMT
  6. Organization: AT&T Bell Laboratories, Murray Hill NJ
  7. Approved: austern@mti.sgi.com
  8. Message-ID: <DKrnsG.7J7@research.att.com>
  9. References: <4ciauq$2e1@trojan.neta.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. Keywords: RTTI
  12.  
  13.  
  14. In article <4ciauq$2e1@trojan.neta.com> jgreen@amex-trs.com writes:
  15.  
  16. >     It seems that RTTI requires a compile time flag to be activated. When
  17. > activated the code seems to bloat whether you actualy use the feature in the
  18. > specific peice of code or not. From what I have learned this overhead is due
  19. > to extra work done when the object is constructed (A pointer to this with a
  20. > string representation of the class is added to a table). This overhead does
  21. > not make RTTI a good addition to C++ but more of a optional addition to those
  22. > who want it (this is how it is implemented now). Also are the addition of key
  23. > words which is not a biggy in this case given the key word names.
  24.  
  25. There's nothing I can think of in the language that requires
  26. it to be implemented that way.  It is intended to be possible
  27. to implement RTTI by adding an extra field to the virtual function
  28. table, which means there is a small amount of space overhead per
  29. class (not per object) and no time overhead except for the places
  30. in the program where RTTI is actually used.  I can see no reason why
  31. any extra work should have to be done when objects are constructed.
  32. -- 
  33.                 --Andrew Koenig
  34.                   ark@research.att.com
  35.  
  36.